How can one depend directly on a package from a github repo? (Assuming the project has no baseline, or there is a reason not use the baseline.)
I've tried the following spec
spec
package: 'Magritte-XMLBinding'
with: [ spec
repository: 'github://magritte-metamodel/XML-Bindings:master/repository' ].
However it failed (Could not resolve: Magritte-XMLBinding [Magritte-XMLBinding.package]), and in Monticello browser under the repo I see only Magritte-Tests-XMLBinding.
What is more, when I look at the unpacked repo (in github-cache/), only the Magritte-Tests-XMLBinding has been unzipped.
The unpacked Tests package is the first in alphabetical order, which makes me feel like Metacello spec just grabs the first package without thinking.
When using git (and github), you cannot depend on packages but in complete projects. You can, however, depend on a project but load just one package of that project.
normally this definition should work:
spec
baseline: 'XMLBindings'
with: [
spec
repository: 'github://magritte-metamodel/XML-Bindings:master/repository';
loads: #('Magritte-XMLBinding') ].
However, while this answer is correct in general, in this case it will not work because the author of the project didn't included any baseline definition that would allow this kind of dependency definition to work, which suggests me he just uses that project as a mirror of the real one... so here you have three possible solutions:
send a pull request to author with a baseline
contact the project author and ask to add a baseline
use the original source instead the github mirror
Related
Error log
Liquid Exception: Liquid syntax error (line 6): Unknown tag 'include_cached' in /_layouts/post.html
I am currently making a blog by forking this project at https://github.com/hydecorp/hydejack.
I've tried several methods for 2 days, but it doesn't work. Locally it's fine, but when I build I get an error.
this is my project
https://github.com/JangHwanPark/JangHwanPark.github.io
I tried changing config.yml and layout to md file. I also tried deleting the repository, but it didn't work.
When you build the way you do, the "classic" way (as opposed to using an action), GitHub uses a fixed configuration and a list of whitelisted plugins (visible here). It really only includes the github-pages gem, which includes all other dependencies. Your Gemfile is ignored for the build; among other things, this means the build uses Jekyll v3.9.2, and not v4.1 as in your Gemfile.
There are two approaches:
Stick with the "classic" experience. I recommend you make your local environment match that; the Gemfile simplifies to
source "https://rubygems.org"
gem "github-pages", "~> 227", group: :jekyll_plugins
Don't forget to run bundle install after you've updated the Gemfile so the lockfile gets updated, too.
You'll have to update _config.yml to include your theme via the remote-theme plugin, and add the include-cache plugin to the plugins list.
This closely matches what the docs for your theme also recommend.
Switch to a custom GitHub Actions flow to deploy your page. There is a starter workflow for Jekyll; using that should get you most of the way there. You might still have to specify remote_theme in the config instead of theme, unless you copy the entire theme into your repo.
Doing this lets you use any gems you want, and any Jekyll version you want.
We're running into a problem with our NuGet pipelines on GitHub. We have it set to run a step to build the project, and NuGet pack it with a specific version (the RC version generally something like 1.0.0-rc.1) this works fine, and we can then pass the artifact to the RC step and upload it to where it needs to go using NuGet push.
The problem comes in when we're trying to then move that package from RC into GA (the desired flow being: build > RC > GA), we want to take the same exact package and modify the version so it no longer has the RC tag (stripping it down to 1.0.0), however I haven't been able to find a clean way to do this. The current workaround is to take the exact same commit and rebuild it with the GA version but we would much rather just modify the RC version to have the correct version number.
Is there a NuGet command or something that I'm missing to accomplish this? I considered downloading the nupkg file, installing it to an output directory and then repacking it with the correct version but I was hoping there may be a better way.
Few options using Action Update Helpers,
the diff. is helpful depending on what you are publishing, nuget libs you are publishing vs. custom libs - since you did not share your sample yaml/code, I am sharing both.
Option 1: use the Release Tag Updater helper lib. from here or a newer one here from Github or Market Place
Helpful for your own, i.e if you publish NUGET libs
In your yaml configuration file for github actions, in the stage that you want to rename you can use the tag option with passed in values
# Filepath of the project to be packaged, relative to root of repository
PROJECT_FILE_PATH: YourProject/YourProject.csproj
# NuGet package id, used for version detection & defaults to project name
# PACKAGE_NAME: YourProject
# API key to authenticate with NuGet server
NUGET_KEY: ${{secrets.NUGET_API_KEY}}
# NuGet server uri hosting the packages, defaults to https://api.nuget.org
# NUGET_SOURCE: https://api.nuget.org
# Filepath with version info, relative to root of repository & defaults to PROJECT_FILE_PATH
# VERSION_FILE_PATH: Directory.Build.props
# Regex pattern to extract version info in a capturing group
# VERSION_REGEX: <Version>(.*)<\/Version>
# Useful with external providers like Nerdbank.GitVersioning, ignores VERSION_FILE_PATH & VERSION_REGEX
# VERSION_STATIC: 1.0.0
# Flag to toggle git tagging, enabled by default
# TAG_COMMIT: true
# Format of the git tag, [*] gets replaced with actual version
# TAG_FORMAT: v*
Option 2: Modify/roll your own yaml properties file
IMHO for your Custom Libs, i.e. if you need something beyond the standard yaml properties and you need some more.
For e.g. in your final release stage, use the yaml deploy section to name it what you want using this lib.
# your previous yaml code ... there should be a section with the below tage configured and it will look for it an update.
The main differences is one targets the major and minor release of the tag names and helpful for Nuget packages.
The second one allows you to create something beyond and custom as a tag.
What is the best practice for managing dependencies within a Simulink Project when the project is worked on across a team and the project has dependencies on different models and libraries?
An parallel example would be when building an application using Gradle and declaring the dependencies of a project including the required version numbers. Grade will resolve and download the versions that are required to build the project.
e.g. the following declares a dependency on version 2.1 of library and version 1.0 upwards of some-library, so that the latest version 1.x (1.0, 1.1, 1.2...) that is available will be downloaded and used.
dependencies {
compile("com.example:library:2.1")
compile("com.example:some-library:1.+")
}
The documentation for Simulink (and also here covering manifests) seems to talk about models within a project having version numbers. It doesn't seem to mention libraries that are imported into the project. Models that are only used within a single project could all be contained in the overall project, but what happens if there are (for example) generic S-Functions defined within a separate project or library (or library defined within a project) that are applicable across multiple projects? This requirement is all with the aim of helping to support an automatic build process triggered by a Continuous Integration server, such as Jenkins.
I'm interested in a workflow that will easily support dependency management and automatic dependency resolution with a Github Flow git branching policy.
I've spent much time on this problem. Finally I didn't find an appropriate solution online, but I'd like to share the workflow we are using now and which fulfills our needs.
In short: We created our own dependency management by using git submodules.
Assumption: In fact, it is more a version management of persistent dependencies rather than offering the possibility to dynamically add new or remove old packages or libraries. This also works, but requires the git submodules to be added to or removed from the main git repository.
Objectives:
Consistent setup for everyone who works on the project.
Traceability of depdendencies.
Continous Integration with less effort.
How we do it (Example):
We have Project A and Project B which shall be used in Project C.
All three projects are under git version control and still under development.
We have set up additional release repositories for Project A and Project B, e.g. located on a network drive.
In Project C we add the release repositories of Project A and Project B as git submodules
We have set up some kind of auto-deployment to push only relevant files into these release repositories. For example if we want to make changes of Project B accessible to Project C, we only create a version tag in Project B's repository and it gets pushed to its release repository.
In Project C we update our git submodules and can checkout a new submodule version (if needed).
Advantages:
Since git stores the checked out version (commit) of git submodules in the main project, we can ensure that everyone works with the same files.
Changing the commit of a submodule is traceable in the main project.
The relation between the main project and the dependencies is always consistent.
Continuous Integration should work "out of the box". We are using GitLab and GitLab Runner and only had to setup our runner to fetch submodules recursively (in case of nested submodules).
I think this approach works as long as the repositories won't get too big, since you do not fetch only the version you need but also the whole version history.
There is a port of shapeless library to scala-js (https://github.com/alexander-myltsev/shapeless). I need to publish artifact properly with fewer possible dependencies to original shapeless.
Now I forked Miles Sabin's repo, and added changes required to generate scala-js library: add scalajs-sbt-plugin, tune build.scala, add bintray-sbt-plugin.
It is wrong to ask shapeless maintainers to merge my branch because scala-js could broke their build.
On the other hand I'd like to have minimal dependencies to original repo as well. Theoretically and ideally what I'd like is to create, say, shapeless-scalajs sbt-project from scratch. Then reference somehow original shapeless library. And then derive from shapeless-build-scala with required overrides to build it against scala-js and publish to my bintray.
I believe in almighty sbt :) What are my options to solve this task?
I think the easiest way is (no sbt hackery involved):
Fork shapeless
Create Scala.js branch
Change build files as you need. That is, modify the shapelessCore project directly as in your PR. (add scalaJSSettings, your repo coordinates)
Commit
Publish shapeless to your maven central
When a new version of shapeless comes out, just merge shapeless/master with your scala.js branch. If no changes happened to the build file, this will merge just fine.
Re-publish
This will be way easier than an sbt project that depends on an external project (which is doable, but doesn't directly allow you to reuse settings etc.)
I'm dealing with two repos:
- A github repo that contains a bunch of text files.
- A scala project that would like to read those text files.
I would like to use SBT to download the contents of the github repo as a build dependency.
I wouldn't mind if SBT supplied either a path (into the ivy repo?) for the project to use or build them into the projects available resources - or any other way that will just work. I'm aiming for something automatic; clearly there are ways I could do this manually.
If you talk about a bunch of text files like *.property for example that used as dependency for your project (do you really want download them every time?) you may use sbt.IO.download(url: URL, to: File). Just create task and add to project definition compile <<= (compile in Compile) dependsOn myDownloadTask After that you may process them as regular local files ;-).
IMHO you understand that you may add custom logic like caching or page parsing or REST request to GitHub to your project definition. At last you may create your own SBT plugin - there are few video tutorials "How to create SBT plugin in 5 minutes" on YouTube.