I have a multi module GitHub project which I would like to build using GitHub actions. The action script that I have written is a publish script that triggers when a tag is pushed. I need two things here that should work out, but before here is my project structure:
main-project:
build.sbt
module1:
build.sbt
src/main/scala/....
module2:
build.sbt
src/main/scala/....
I need to have a mechanism check that does the following:
When I push a tag, I will trigger my workflow and I would like that my workflow is only publishing module 1 changes
Is there a way to git tag only module 1?
If you only ever want to publish module1, you can set publish / skip := true in the project settings in build.sbt for other modules and the root project.
If your modules are on different paths within the same Git repository, you could use a path-filter action, as illustrated here.
Note that you cannot tag just a part of a repository, but, if your changes involves only that one module, you can then decide apply a (global) tag with a naming convention reflecting the nature of the change (IE only module1 or only module2).
Related
I have a GitHub repo and would like to use GitHub Actions to create a release with a generated file included:
push a commit with a tag
the GitHub Action starts
it runs yarn run build (generates dist/index.js)
release is created that includes the dist folder
So far, I have not been able to do this. I've been able to use "marvinpinto/action-automatic-releases#latest" action to package the dist folder as an additional asset, but that's not it.
I want the Source code (tar.gz) in the GitHub release to contain the dist folder.
What I'm trying to do is use this generated asset as a yarn dependency, which works if I use the Source Code (tar.gz) but not if I use the additional generated asset.
The entries your images show that are labeled “Source code (tar.gz)” and “Source code (zip)” are autogenerated from the contents of the repository and contain only and exactly what's in the repository. They can't be modified in any way because they aren't persisted: they may be regenerated in the future. That's also why they may change (so, for example, the hash of the contents need not be stable).
If you want to include additional dependencies in your tarball, simply upload your own source release that contains the generated files. Many projects do this for various reasons, and you can do it, too.
i have a scala js sbt project, i developped in this project new user interface components.
the person p1 has a project with the same structure (same build.properties & plugins.sbt), how can he access to my user interface components.
Should i add some specification in build.sbt ?
If you want to share some project settings, you can create a sbt plugin - it will allow you to have some common settings, add dependencies to other sbt plugins and even override their configuration. See for example sbt-softwaremill as a example of plugin that is used to share some commons between projects.
It won't magically update all configs, because:
build.properties is evaluated before the sbt code is run
you have to add this plugin to plugins.sbt
you have to create project structure in each project
Any more config sharing than that is theoretically possible by e.g. using git submodules and commiting symlinks to repo, but that would be pretty wrong - any change to one project would result in a change in another project, and you have them separated for a reason - if both projects were the same you would have one project in the first place.
And if you are need to share the code itself, you can build the code, publish it to an artifactory and add dependency in another project.
But that's only if you really have two projects, and it's entirely possible that you just need to have one git project with different branches, where ever developer would work on their own branch and then merge changes to common branch, bacause that's the point of using git.
I have a main repository which is core router for mine system modules.
So every module is a standalone repository also.
How can I make that pushing to main repository will fire event to push the updated code to standalone repository?
Just as like https://github.com/Sylius/Sylius - they have main repository (this link) in which they collect pull-requests and standalone repositories like https://github.com/Sylius/SyliusTaxonomyBundle which exists in src/Sylius/Bundle/TaxonomyBundle
Don't they manually push the updates to standalone repos? Or some kind of github hooks? git subtree?
And why they do have the "replace" section in composer.json? How does this works? I didn't get an idea from official documentation :((
Sylius (and Symfony) create separate repositories for their components and bundle so that they can be used independently with composer. They only work in a single repository and use subtree to split the components and bundle into read only repositories.
I don't believe they are technically read-only, this is just an easier workflow than having to pull changes from the subrepo's in every time.
They probably use something like Git Subsplit GitHub WebHook to automatically update the subrepo's.
Using they replace key means that Sylius/Sylius contains Sylius/SyliusCartBundle in its self.
So when using a project which uses Sylius/Sylius and Sylius/SyliusCartBundle, Composer knows not to download Sylius/SyliusCartBundle because it is already provided by Sylius/Sylius.
our project structure has been split. On the one hand there is the /plugins folder containing all main plugin projects. On the other hand we have a /tests folder containing all the fragment projects that are the unit tests for their corresponding main plugin projects.
Jenkins lets me check out multiple repositories, and even to the same folder in the workspace.
The problem is that the first checkout is deleted when the second URL is checked out.
/plugins is placed into the workspace directory, then the workspace directory is "cleaned":
Cleaning local Directory .
Then the second directory /tests is checked out.
Of course I want that both folder contents are placed in the same workspace directory. How can I do that?
Assuming you're using Subversion to checkout your projects, you need to specify the "Local module directory" to something other than the default for each path you are checking out.
For example;
If you have svn://myrepo/myproject/plugins and svn://myrepo/myproject/tests, the configuration would be along the lines of;
Modules:
Repository URL : svn://myrepo/myproject/plugins
Local module directory (optional) : plugins
Repository URL : svn://myrepo/myproject/tests
Local module directory (optional) : tests
This would then inform Jenkins that it has two paths to checkout and into separate locations.
If you are trying to checkout a project into the subfolder of another working copy, you may have to use svn:externals on the parent directory.
In the new Jenkins 2.0 pipeline (previously named the Workflow Plugin), this is done differently for:
The main repository
Other additional repositories
Here I am specifically referring to the Multibranch Pipeline version 2.9.
Main repository
This is the repository that contains your Jenkinsfile.
In the Configure screen for your pipeline project, enter your repository name, etc.
Do not use Additional Behaviors > Check out to a sub-directory. This will put your Jenkinsfile in the sub-directory where Jenkins cannot find it.
In Jenkinsfile, check out the main repository in the subdirectory using dir():
dir('subDir') {
checkout scm
}
Additional repositories
If you want to check out more repositories, use the Pipeline Syntax generator to automatically generate a Groovy code snippet.
In the Configure screen for your pipeline project:
Select Pipeline Syntax. In the Sample
Step drop down menu, choose checkout: General SCM.
Select your SCM system, such as Git. Fill in the usual information
about your repository or depot.
Note that in the Multibranch Pipeline, environment variable
env.BRANCH_NAME contains the branch name of the main repository.
In the Additional Behaviors drop down menu, select
Check out to a sub-directory
Click Generate Groovy. Jenkins will display the Groovy code snippet
corresponding to the SCM checkout that you specified.
Copy this code into your pipeline script or Jenkinsfile.
I've got a project in a git repository that uses some custom (and so far unversioned) setup scripts for the build environment etc. I'd like to put these under version control (hopefully git) but keep them versioned separate from the project itself, while still living in the base directory of the project - I've considered options like local branches but these seem to have the problem that switch back to master (or any other "real" branch) will throw away the working copies of the setup scripts.
I'm on Windows using msysgit so I've got a few tools to play with; does anyone have a recommendation or solution?
If you really need them separate from your main git repo while still living directly within it, you could try:
creating a new repo with those script within it
and:
adding that new repo as a submodule to your repo. Except:
a/ those scripts won't live directly in the base directory, but in a subfolder representing the submodule
b/ you need of course to not publish (push) that new repo, in order for other cloning your main repo to not get those setup files
or:
merging that new repo into your main repo (with the subtree project), but:
you need to split back your project to get rid of those files
for a project with a large history, and with frequent push, that step (the split) can be long and cumbersome.
I would consider a simpler solution, involving some evolution to your current setup files:
a private repo (as in "not pushed") with those setup files
environment variables with the path of your main git repo in order for your setup files (which would not be directly within the base directory of said main repo) to do their job in the right directory (like beginning for instance with a 'cd right_main_git_repo_dir').
I want to share an additional solution and some samples from which to start.
I've has a similar problem in attempting to build Mozilla Firefox with Buildbot -- I need to have some files in the root folder (namely the .mozconfig file and some helper scripts) and I wanted to version them separately.
My solution is as follow:
checkout the Firefox code from the Mercurial repository;
checkout an additional repository with the additional file I need;
before starting the build, I copy these file to the folder with the Firefox code.
This approach is implemented in the following repositories:
buildconfig-mozilla-central: it contains the Buildbot configuration, which
pulls both repositories
copies the files from the scripts repository
and start the build;
buildscripts-mozilla-central: the repository with the build configuration and helper scripts.
Please note that the code might not be well factored (for example the paths) but it should be a good starting point.
This procedure is tailored for Firefox, but it can be applied to any repository.