Due to the relative simplicity of our site and limited resources, we're using one machine as both our development and staging server using a self-hosted github runner. It connects via SSH and runs actions triggered by pushes to two different branches. What I'd like to do is have two github actions scripts execute for two different branches of the same repository, we'll call them dev and stable for repository projectA. dev would deploy to ~/actions_runner/_work/projectA/projectA-dev and stable to ~/actions_runner/_work/projectA/projectA-stable, then use individual ENV files to connect them to the appropriate versions of their support services. It's unclear how to configure each script to rename the directory for their branch. Currently, the development workflow (a single script) deploys to ~/actions_runner/_work/projectA/projectA automatically... it seems like it should be possible to change the second instance of the repository name in the path to something more customized. Is it?
I looked at the github actions documentation about deploying to specific locations and haven't seen anything. I also searched github, reddit and google. Nothing I've found has helped! Thanks in advance.
It's unclear how to configure each script to rename the directory for their branch
Ideally, you do not rename anything, but use each action to checkout in your runner workspace to two different paths.
That way, you can use projectA-dev/stable in each action.
- name: Checkout tools repo
uses: actions/checkout#v3
with:
repository: my-repo
path: projectA-dev
Related
I'm beginning to understand how Heroku works, but haven't yet used a pipeline. I have an app I'm working on that is near its first production version. I'd like to begin using pipelines.
But I don't understand how to begin. What do I need to do to make a copy of the current app and have that copy be in the development stage and make another copy for the staging stage? Do I fork my git repository twice and add each one?
I'm trying to take this one step at a time. I don't need GitHub integration yet. This is a small project and will not have any pull requests for quite some time, if ever. I'm only interested in the ability to develop, stage and release in the three stages offered by Heroku.
While pipelines do use multiple apps, they should use the same git repository with different remotes. Heroku's help page helped me understand that the process is to link the repository to each app different remote names and then push to the remote that I'm currently working on.
What we use:
We use mercurial and bitbucket for repositories. Appveyor and kudu for continous integration and deployment. We are using visual studio 2015 as IDE.
What we have:
We have different web projects. They share some other projects. All of web projects have their own solution. Every solution have their own repository.
If there is change on develop branch. Appveyor builds this repository, tests and deploys it.
If there is change on default, kudu builds this repository and deploys it.
What we want:
We want to merge all of these projects in one solution. But I couldn't figure it out, how I can achive continous integration or deployment.
If I change something on webproject1, I just want to build and deploy webproject1. The other webprojects in solution neither should be built nor deployed.
Perhaps a single repository will help you. Using relative path to include the shared libraries from your different applications.
Each application can still have its own Solution file and your CI setup also stays as it is. What changes is that the shared projects you have across all applications will be referenced with relative path. E.g.:
Repository root\Core\Component1\Component1.csproj
Repository root\Core\Component2\Component2.csproj
Repository root\Applications\App1\App1.sln
Repository root\Applications\App1\Domain\Domain.csproj
Repository root\Applications\App1\Web\Web.csproj
Repository root\Applications\App2\App2.sln
Repository root\Applications\App2\Domain\Domain.csproj
Repository root\Applications\App2\Web\Web.csproj
Now your different application can include the Core\Components they need by adding existing project to solution using relative path.
Your continuous integration system will have VCS triggers watching the app and dependencies so only relevant changes fire a build.
So if App1 developer makes a change on Component1, and Component1 is also used by App2, the build server will trigger a build to App1 and App2, signaling any breaking changes. However if App2 doesn't not depend on Component1, then only App1 will build.
This is achieved by configuring the build triggers for your applications.
One benefit of this strategy vs having a single .sln is that you won't have to build everything each time you build solution (nor configure what projects to build each time you work on a different app)
Also note that you can achieve this with multiple repositories. But that means you'd need to check them out at the correct location so your relative paths work. It's also quite obscure since if you checkout App1 and try to build it. It simply won't work and you'll have to figure out which other repos to check out, etc.
You are using Mercurial but FYI, the way (one of) this would be handled with Git is with submodules.
Is there any CI/CD tool for Netezza that can manage versions and can be used for migrating code across environments? We have used flywaydb for other databases and are happy with it, but that does not support Netezza. I have already googled and did not find a single tool, so any responses are good for me to begin analyzing further
To my knowledge, there's nothing specifically geared for Netezza. That said, with a bit of understanding of your target environment, it's certainly possible.
We use git and GitHub Enterprise (GHE). The reason for GHE is not particular to this solution, but rather because I work at a hospital. Here's what we do.
Setup
Build a repository at /home/nz on your production server. Depending on how you work nzlogs, nzbads, and other temporary files, you may need to fiddle quite a bit with the .gitignore file. We have dedicated log directories where temporary files should reside.
Push that repo into GHE.
If you have a development server, clone the repo in the /home/nz directory on that server. Clearly you'll lose all development work up until that point and will want to make sure that things like .bashrc are not versioned. Alternatively, you could set up a different branch and repo and try merging the prod and dev versions. We did this, but I'd recommend just wiping your development box with production code one slow day.
Assign your production box a dedicated branch in git. For this discussion, I'll call them prod and dev. Do the same for development, if you have it. This is mainly a mental thing, not a tech thing, but it's crucial, like setting up a remote for Heroku or Azure.
Find or develop a tiny web server that can listen for GitHub webhooks. I built a Sinatra server with a simple configuration file. Anything will do. Deploy the web server to each of the environments and tune them to perform the following activities on an update to the prod or dev branches, respective to the server.
git reset --hard
git clean -f
git pull
Set up webhooks in your GHE repository to send the push event to the web servers.
Of course, you can always have the web server do other things on a branch update if you want to get fancy (maybe update cron from a versioned file or update schemas from all new files).
Process
Fairly simply, follow the GitHub Flow workflow. You can pretty much follow whatever process you want with the understanding that your prod and dev branches should be protected and only removed or futzed with as an admin task. Create a feature branch, test it by pushing to dev, and then make a pull request for the prod branch.
Why GHE? Mainly because it keeps an open area where our code is available. You could absolutely do this by pushing directly to Netezza's git repo, but your workflow will suffer--it just isn't as clean as having all code in one clear place with discussion around pull requests.
I face a problem, common I guess.
I have a project which is store in github.
I need it to run for: production, testing and different developers.
The project uses maven profiles to set some parameters.
The project has also a spring profile: currently only DEV which initialize a DB.
The project uses external software with specfic configuration files.
I need to have the project in production but being able to serve development versions.
The question: can I use git ignore locally within developers to distribute the code and still store the files in github?
Or would you have a different solution?
The actual question is:
Can I use git ignore locally for some configuration files and still have the files on the main repository? Updated by only the production users?
One way is to store:
one different configuration file per environment
one template file
one script able to detect the current environment the git repo is cloned in, and generate the actual configuration file (which isn't versioned) used for that local environment.
That generation can be automated on checkout, with a smudge script declared as a content filter driver.
The way we have solved this is with a configuration script that pulls the server-appropriate credential file for local, staging, or production from a separate repository.
After each server pulls the appropriate file, we rename it for consistency across the different environments, and then we have our settings file which is tracked by git include the credentials file.
I work on a website on multiple computers, my work and my home pc. The source is maintained under a git repository. I use Web Deploy to publish the website to IIS on the public server. Everything works OK, I can publish from both computers and it works.
The issue is that when I deploy from one PC, then go to the other, get the latest changes from git, make more changes, then deploy again, it re-deploys the entire website instead of only the files that have changed - as is what happens if I were to take out the "then go to the other, get the latest changes from git" steps from the first sentence of this paragraph.
What can I do, what files can I include in my git repository (I exclude all packages, bin and obj directories), or what extra configuration can I perform, to resolve this?
Add a repo on your public server, push to that, then deploy from there. The push will be minimal, git can be startlingly good with deltas.