Optimizing Via Path and Concurrency - github-actions

I am trying to figure out how to optimize our builds by only building and testing what needs to be built and/or tested.
Let's say we have a 3-tier app in a single repository with structure with three "main" directories for each tier ("data", "api", "web") such as the below example.
.
├── data
│ ├── entities
│ ├── blah
│ ├── blah2
├── api
│ ├── blah
│ ├── blah2
├── web
│ ├── blah
│ ├── blah2
I would like:
if there is a change in source code in "data" - do a "full" build (build "data", "api" and "web)
if there is a change to source code in "api" - build "api" and "web" only
if there is a change to source code in "web" - build "web" only
I have been able to essentially accomplish the above using the "paths" element of the github action workflow. For example, in the web.yml workflow:
on:
push:
paths:
- 'web/**'
Or, in the api.yml workflow:
on:
push:
paths:
- 'api/**'
But, if the commit contains changes in more than one folder, this becomes problematic, because more than one workflow will start.
There's some ability to use concurrency: as below:
concurrency: ${{ github.ref }}
And, there's even the ability to use cancel-in-progress as below:
concurrency:
group: ${{ github.ref }}
cancel-in-progress: true
But, here's the issue. How is there any priority to the cancellation?
For example, say a change is made to all three paths and all have the cancel-in-progress, how does github actions determine which two of the three to cancel.
Is there anyway to specify priority? In other words, can I specify in somewhat to keep the "full" build (or where paths: data)?
I can't figure out how to structure this to keep the workflow that starts the build in the correct spot in the dependency chain.
In other words, I would like:
If a change is made to all three, keep the "full" or "data" workflow
If a change is made to "api" and "web", keep the "api" workflow
If a change is made to "data" and "web", keep the "data" workflow
Thoughts?

Related

ShellNew Regedit Key is doing nothing

I would like to add the "c" file in the "New File" button in the Resources Explorer by the System Register Editor:
I followed a tutorial on how to add options to the "New File" button in the Resources Explorer, and I added a "NewFile" Value in the ".c>ShellNew" Key I just made, with the value Template.c, after creating an empty file in the folder Windows>ShellNew (The folder is correct since I have AutoHotkey installed and there is "Template.ahk").
This is the register structure:
│ ├─.c
│ │ ├OpenWithProgids
│ │ ├PersistentHandler
│ │ └ShellNew
And these are the Values in each Key:
OpenWithProgids: (Default) REG_SZ (value not set)
PersistentHandler: (Default) REG_SZ {5e941d80-bf96-11cd-b579-08002b30bfeb}
ShellNew: (Default) REG_SZ (value not set)
FileName REG_SZ Template.c
My default handler for ".c" files is Notepad++.
I would like to know if the infos I provided are enough to solve the problem, and I am sorry if I have chosen the wrong platform to ask, I am new to coding, Register editing and Stack Overflow in general.

Mkdocs with material theme: is it possible to change site name according to language?

I'm making a documentation site using Mkdocs and mkdocs-material theme (https://squidfunk.github.io/mkdocs-material/getting-started/). I need to make a multilanguage project ('pt' and 'en' for now). What i'm in need is a way to change the site name according to language that the person ir reading.
E.G: I'm in Brazil, so i'll read in portuguese (pt), and the site name must be "Name in Portuguese". Another reader, in USA, for example, will read in english so the site name muste be changed to "Name in English".
My project till now is with a tree of docs like this:
docs/
|
|__ index.md
|
├─ en/
│ ├─ somefile1.md
| |__ somefile2.md
├─ pt/
│ ├─ otherfile1.md
| |__ otherfile2.md
My yaml mkdocs.yml file configuration is in the root of project, one level above the docs dir (standard for mkdocs).
site_name: Name in Portugese
site_url: mysiteproject.com
nav:
- index.md
- Ajuda:
- pt/otherfile1.md
- pt/otherfile2.md
- Help:
- en/somefile1.md
- en/somefile2.md
theme:
name: material
logo: imgs/logo-serpro.png
favicon: imgs/favicon.png
language: pt
font:
text: Open Sans
markdown_extensions:
attr_list: {}
admonition: {}
codehilite: {}
meta: {}
extra_css:
- css/extra.css
So, what I need is, when the reader is navigating the site on "Ajuda" section, the site name will be in portuguese. If the reader is on "Help" section the site name change to "Name in English".

How to add permalink and variables globally to Jekyll pages inside a specified directory

I'm setting up a website with multi language support.
In the root directory I have one or more directories based on the language locale, e.g.: /en /it
I'm trying to set one language as default and let Jekyll generate its pages in the root of the _site directory, by setting the defaults section in _config.yml as described below. Other directories will be generated as usual.
I don't want:
to use a plugin since it have to work also with GitHub pages
to set a lang: en variable in each page front-matter but setting it globally in _config.yml instead if possible
put a load of files/directories in the root directory, just the various en, it, fr etc (if not having something like described below, but using a master pages directory).
I tried various solutions, including:
using collections: it works as expected with the example below but I don't want to use them for various reasons, like not having sitemap plugin working with them
using this solution, but it doesn't work with multiple pages with same name and other types of documents
This works with collections with an _en directory in the root:
collections:
en:
output: true
permalink: /:path
defaults:
...
- scope:
path: ""
type: "en"
values:
layout: "default"
lang: "en"
permalink: /:path
Not this, IMHO as it should be for pages:
defaults:
...
- scope:
path: "en"
type: "pages"
values:
layout: "default"
lang: "en"
permalink: /:path
In brief I need:
custom variables set for each page in the specified directory globally instead in each page front matter
make Jekyll to generate all pages from the specified directory to build in the root of _site directory using a global permalink

Prose.io content management workflow explained

I'm looking into prose.io and I would like to find out more about the content management work flow.
Do prose.io content contributors get access via prose.io to the master repository on GitHub or do they work on a branch or even on a fork?
I'm wondering how much can go wrong and how messy the master repo gets when everyone has access?
Is there an option to combine pull requests with prose?
Using prose for my personal blog and its the master repo prose gets access to.
However there is something you can do. In Jekyll _config.yml you can set prose parameter option for rooturl: "DIRECTORY NAME" what this does is limits the prose access to directory. In my case there is directory called _posts and prose cannot edit anything outside of it. There is also ignore option that basically makes folders invisible on prose. I
Here is my prose config for use as an example. Here I use both root and ignore options.
prose:
rooturl: '_posts'
media: 'img'
ignore:
- 404.html
- LICENSE
- feed.xml
- _config.yml
- /_layouts
- /_includes
- /css
- /img
- /js
metadata:
_posts:
- name: "layout"
field:
element: "hidden"
value: "post"
- name: "title"
field:
element: "text"
label: "Post title"
placeholder: "Title"
alterable: true
- name: "subtitle"
field:
element: "textarea"
label: "Subtitle"
placeholder: "A description of your post."
alterable: true
- name: "date"
field:
element: "text"
label: "Date"
help: "Enter date of post."
placeholder: "yyyy-mm-dd"
alterable: true
- name: "published"
field:
element: "checkbox"
label: "Publish"
help: "Check to publish post, uncheck to hide."
More on the options here >
https://github.com/prose/prose/wiki/Prose-Configuration
Prose doesn't necessarily commit to master, rather it commits to your default branch. That is usually master, but you can change it. For instance, if you're using GitHub Pages your default branch would be gh-pages.
In our workflow, we're now trying to separate the branch that contributors edit on from the version we use for production. We leave the default as master (for simplicity), but keep our production version in a separate branch (e.g. production). Project owners then carefully merge or cherry pick from master into production.
Prose may soon allow you to change the branch it commits to from the GitHub default branch, at which point we'll revisit our workflow.

sass/scss/compass: how to set default project file structure

At the first, i am new to sass/compass and think it is a big step forward. But I still have a small problem. I try to set a default folder structure for new projects.
So, if i create a new project with:
compass create
it outputs the following folder structure for example:
├───.sass-cache
├───sass
│ ├───ie.scss
│ ├───print.scss
│ └───screen.scss
└───stylesheets
├───ie.css
├───print.css
└───screen.css
what can I do now, to say compass that I want a structure like that, for every new project:
├───.sass-cache
├───css
│ ├───ie.css
│ ├───print.css
│ └───screen.css
├───img
│ ├───ico
│ ├───jpg
│ └───png
├───js
│ ├───jquery-1.7.2.min.js
│ └───scripts.js
└───sass
├───ie.scss
├───print.scss
├───screen.scss
├───_config.scss
└───_mixins.scss
Is there a default-config.rb where i can define which files to load or do I have to create this structure manually for every new project?
I thank you in advance!
EDIT
Okay, I have found the best answer by myself:
Just create an extension for compass. So you can build your own folder & file structure.
Here is a nice starting point.
To create then a new project enter that compass create <project-name> -r extension_name -u gem_name into the terminal/console.
For everyone who needs a starter kit for that, take a look at my port of the "Kube Framework": compass-kube
Your preferred project structure isn't something Compass should handle. Instead, you should have your own skeleton, barebones, bootstrapped, template starting point which you copy to start new projects:
cp -r ~/barebones-project-starter .
or clone from a hosted version control system:
git clone https://github.com/kumiau/default-project
I don't think compass have this particular functionality. The closest thing i think you could do is fork the project on GitHub and modify it to your needs.
https://github.com/chriseppstein/compass
Just set dirs you need here:
%Ruby_Folder%\lib\ruby\gems\2.2.0\gems\compass-1.0.3\lib\compass\app_integration\stand_alone\configuration_defaults.rb